Network address translator application programming interface

ABSTRACT

An application programming interface (API) for an intelligent transparent gateway is provided. The API interfaces the gateway with a generalized network address translator (gNAT) at the kernel level to allow user-mode proxy control. Initially, the proxy binds to a local socket and commands the API to generate a dynamic port-redirect in the gNAT for all connection requests for a given port to itself (at the local port to which it is bound). The API also retrieves the address information of the server to which the client has attempted to connect so that a proper translation mapping may be made. The proxy may also request that the API command an address translation in the gNAT so that further messages between the client and the server need not pass up to the user-mode, but may be dynamically redirected within the kernel-mode.

CROSS-REFERENCE TO RELATED PATENT APPLICATION

[0001] This patent application is a continuation of co-pending U.S.patent application Ser. No. 09/537,143, filed Mar. 29, 2000, entitled“Application Programming Interface and Generalized Network AddressTranslator for Intelligent Transparent Application Gateway Processes”.The entire teachings and disclosure of this patent application arehereby incorporated in their entireties by reference thereto.

TECHNICAL FIELD

[0002] This invention relates generally to network address translationand proxy application control of network communication and, moreparticularly, relates to the combination of network address translationand proxy application functionality into a transparent applicationgateway process.

BACKGROUND OF THE INVENTION

[0003] As the number of computers that needed or wanted to be connectedto the Internet continued to grow, it soon became obvious that thisnumber could not be accommodated by the number of available IPaddresses, known as dotted-quads. In response to this address depletionproblem, a method as illustrated in FIG. 2 was devised whereby a numberof computers C1, C₂, etc. could be located on a “private” network 60 andwould use private IP addresses 62 to communicate with each other. Theseprivate IP addresses could be reused on other private networks since noone outside the private network could see these addresses. In order toallow the computers on the private network to communicate with othercomputes S₁, S₂, etc. on a public network, such as the Internet 64, theprivate network utilizes one machine 66 to provide the gateway for allof the computers on the private network to reach the public network.Through the use of the private addresses 62 on the private network 60and the gateway computer 66, the address depletion problem is at leastslowed.

[0004] This gateway computer 66 runs a program called a network addresstranslator (NAT) that has both a private IP address 62 and a public IPaddress 68. As computers on the private network attempt to establishsessions with a server on a public network (or another private network),the NAT changes the source address 70 of the message packets 72 from theprivate address of the client computer to its public IP address. In thisway, the private IP address is not communicated on the public network.The messages all appear to have come from the public IP address of theNAT machine. The NAT maintains a mapping 74 of the translation from theprivate to the public IP address so that when messages are received fromthe public network in response as illustrated by line 76, the NAT canforward them to the proper client machine. This operation of the NAT iscompletely transparent to the client computers on the private network,i.e. they each believe that they are communicating directly with thepublic servers.

[0005]FIG. 3 illustrates this redirect capability of the NAT machine.Specifically, a client machine C₁ attempts to establish a session 78directly with public server S₁ as indicated by dashed line 80. However,when the message from C₁ is detected by the NAT 66, it dynamicallyredirects 82 the message to S₁ and changes the source address asdescribed above. The client process does not know that the NAT haschanged its messages' source address, and continues to believe that itis communicating directly with the public server. Messages from theserver S₁ are dynamically redirected 82 to the client C₁ based on themapping of the address translation. As may be seen from FIG. 4, thisaddress translation takes place at a low level, e.g. at the kernel level84 in a Window's architecture.

[0006] While the NAT has greatly alleviated the address depletionproblem, especially for home and small business networks, itstranslation of source addresses is fixed within its programming. Thatis, the traditional NAT does not allow any application control of theaddress translations that it performs. Additionally, since the addresstranslation is performed on the message packets at such a low levelwithin the kernel 84, the NAT can add almost no value, other thanproviding the raw source address translation. The NAT cannot evenprovide any destination address translations, and does not fully supportapplications that either assume client and server addresses are bothpublic and therefore equally accessible, or require that servers alsoinitiate network sessions to clients. If added value is desired, such ascentralized virus scanning, site blocking (parental-control filtering),white listing, caching (to speed up response-time), data-transformation(e.g. dithering of images to match screen size), etc., a proxyapplication must be used instead.

[0007] Traditional proxies, as illustrated in FIG. 5, are applicationprograms existing in the user mode 86 that serve as the interfacebetween the private 60 and the public 64 network (see FIG. 6). UnlikeNATs, the proxy 88 must be addressed directly by the client machines asseen in the destination address field 90 of message packet 92, andtherefore requires that the client applications C₁, C₂, etc. be setup tooperate with a proxy 88. Many applications cannot do this, or requirespecific configuration changes to allow the use of a proxy, andtherefore a proxy configuration may not be appropriate, or evenpossible, for use with all applications.

[0008] When a proxy application 98 is used, all communications are sentto the proxy in the user mode 86 (see FIG. 5) as illustrated by lines94, 96. The proxy 98 then determines whether and to whom to forward thecommunication on the public network. If the proxy determines that themessage may be passed to a server on the public network, the proxyestablishes a second session 100, copies the data to the second session,changes the source and destination address, and sends out the message(see, also FIG. 7). In operational terms as illustrated in FIG. 7, aclient process C₁ establishes a first session 94 with the proxy 88requesting access to a public server S₁. If the proxy agrees, a secondsession 100 is established with the server S₁ on the public network 64.Since all messages must pass from the kernel-mode network transport,e.g. TCP/IP 102, to the user-mode proxy 98, be copied to a secondsession, transferred back down to the kernel-mode driver 102, andfinally transmitted to the network for the network application's othersession, a significant performance degradation occurs. However, proxysystem promoters have begrudgingly accepted this performance degradationas the inevitable cost of the added value provided thereby.

[0009] Recognizing that the inability of various applications to utilizea proxy system precludes the adding of value to the network sessionsusing these applications, various software vendors have introducedtransparent proxies. Transparent proxies operate like a traditionalproxy in that they provide value to the network connection, and like atraditional NAT in that the network client need not specifically addressthem. The term transparent refers to the fact that the network client isunaware that its communication is being provided up to the proxyapplication. The client thinks that its communication is going directlyto the network server, in much the same way as it does when atraditional NAT is used. However, the communication is actuallyredirected to the proxy application before being sent to the publicnetwork as illustrated FIG. 8.

[0010] As may be seen from this FIG. 8, as a client C₁ on privatenetwork 91 attempts to contact a server S₁ on a public network 64, thegateway machine 93 running the transparent proxy intercepts itsmessages. The transparent proxy operates by performing an addressredirection through a traditional NAT 95 up to the proxy application 97.Once the proxy 97 has processed the message, it is passed back down tobe sent to the server S₁. While this redirection is transparent to theclient thereby allowing operation of the proxy with clients whoseapplications would not allow operation with a traditional proxy, thisredirection is fixed within the NAT 95. This requires that allcommunication be transferred up to the proxy at the application level oruser-mode, and back down to the transport level or kernel-mode prior tobeing transmitted to the server. Therefore, the performance degradationof the traditional proxy discussed above still plagues the transparentproxy system.

SUMMARY OF THE INVENTION

[0011] The instant invention overcomes these and other problems byproviding an application programming interface for intelligenttransparent application gateway processes. Specifically, the inventiveconcepts of the instant invention relate to an intelligent transparentproxy that utilizes an application programming interface for translationof transport-layer sessions and an application programming interface forport-reservation routines to provide proxy services without requiringthat client applications be notified of the proxy at all. Moreparticularly, the inventive concepts of the instant invention relate toa generalized network address translator and associated applicationprogramming interface (API) that allow both source and destinationaddress translations to be made. The API allows control of the NAT bythe proxy thereby providing the benefits of both a proxy server and anetwork address translator (NAT) while minimizing the transmissiondelays normally associated with traditional and transparent proxies.

[0012] With the intelligent transparent proxy of the instant invention,client applications do not know that they are communicating through aproxy, and therefore need not be configured to do so. This isaccomplished by the instant invention by allowing the proxy todynamically command a generalized NAT to effect both source anddestination address translations to, essentially, reroute data flow upthrough the proxy without the client knowing. The address changes aremapped in the gNAT, and result in apparent sessions between differentclients and servers. As the proxy identifies data transfers that neednot be processed by the proxy, the proxy commands a dynamic addresstranslation at the transport layer. This bypasses the necessity oftransferring the data up to the proxy, thereby greatly increasing theperformance of the system.

[0013] As an example of the operation of the intelligent transparentgateway of the instant invention, assume that a client applicationwanted to establish a session from itself to a server on a publicnetwork. The message would hit the translation mapping of the gNAT, andbe converted to a message from client to the transparent gateway. Thetransparent gateway would pass the message up to the proxy forservicing. The proxy is able to then service the message itself, denytransmission of the message, pass the message on without modification,etc. If the message is forwarded to the server, it appears to haveoriginated from the gateway. The translation mapping is recorded so thatany return messages may be forwarded to the client application, if theproxy determines that it is appropriate to do so. This forwarding mayrequire servicing by the proxy or may be passed without servicing,dependent only on the proxy commanded translation in the gNAT. Thiscontrol provided to the proxy is unknown in prior systems.

[0014] Additional features and advantages of the invention will be madeapparent from the following detailed description of illustrativeembodiments that proceeds with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] While the appended claims set forth the features of the presentinvention with particularity, the invention, together with its objectsand advantages, may be best understood from the following detaileddescription taken in conjunction with the accompanying drawings ofwhich:

[0016]FIG. 1 is a block diagram generally illustrating an exemplarycomputer system on which the present invention resides;

[0017]FIG. 2 is a network block diagram illustrating architectural andcommunicative aspects of a traditional network address translator;

[0018]FIG. 3 is an operational block diagram of a traditional networkaddress translator;

[0019]FIG. 4 is an architectural diagram illustrating a traditionalnetwork address translator;

[0020]FIG. 5 is an architectural diagram illustrating a traditionalproxy;

[0021]FIG. 6 is a network block diagram illustrating architectural andcommunicative aspects of a traditional proxy;

[0022]FIG. 7 is an operational block diagram of a traditional proxy;

[0023]FIG. 8 is an architectural diagram illustrating a traditionaltransparent proxy;

[0024]FIG. 9 is an architectural diagram illustrating the generalizednetwork address translator and its associated application programminginterface of the instant invention;

[0025]FIG. 10 is a functional architectural diagram of the instantinvention;

[0026]FIG. 11 is an operational block diagram illustrating an aspect ofthe instant invention; and

[0027]FIG. 12 is an operational block diagram illustrating an alternateaspect of the instant invention.

DETAILED DESCRIPTION OF THE INVENTION

[0028] Turning to the drawings, wherein like reference numerals refer tolike elements, the invention is illustrated as being implemented in asuitable computing environment. Although not required, the inventionwill be described in the general context of computer-executableinstructions, such as program modules, being executed by a personalcomputer. Generally, program modules include routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. Moreover, those skilled inthe art will appreciate that the invention may be practiced with othercomputer system configurations, including hand-held devices,multi-processor systems, microprocessor based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in both local and remotememory storage devices.

[0029] With reference to FIG. 1, an exemplary system for implementingthe invention includes a general purpose computing device in the form ofa conventional personal computer 20, including a processing unit 21, asystem memory 22, and a system bus 23 that couples various systemcomponents including the system memory to the processing unit 21. Thesystem bus 23 may be any of several types of bus structures including amemory bus or memory controller, a peripheral bus, and a local bus usingany of a variety of bus architectures. The system memory includes readonly memory (ROM) 24 and random access memory (RAM) 25. A basicinput/output system (BIOS) 26, containing the basic routines that helpto transfer information between elements within the personal computer20, such as during start-up, is stored in ROM 24. The personal computer20 further includes a hard disk drive 27 for reading from and writing toa hard disk, not shown, a magnetic disk drive 28 for reading from orwriting to a removable magnetic disk 29, and an optical disk drive 30for reading from or writing to a removable optical disk 31 such as a CDROM or other optical media.

[0030] The hard disk drive 27, magnetic disk drive 28, and optical diskdrive 30 are connected to the system bus 23 by a hard disk driveinterface 32, a magnetic disk drive interface 33, and an optical diskdrive interface 34, respectively. The drives and their associatedcomputer-readable media provide nonvolatile storage of computer readableinstructions, data structures, program modules and other data for thepersonal computer 20. Although the exemplary environment describedherein employs a hard disk, a removable magnetic disk 29, and aremovable optical disk 31, it will be appreciated by those skilled inthe art that other types of computer readable media which can store datathat is accessible by a computer, such as magnetic cassettes, flashmemory cards, digital video disks, Bernoulli cartridges, random accessmemories, read only memories, and the like may also be used in theexemplary operating environment.

[0031] A number of program modules may be stored on the hard disk,magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including anoperating system 35, one or more applications programs 36, other programmodules 37, and program data 38. A user may enter commands andinformation into the personal computer 20 through input devices such asa keyboard 40 and a pointing device 42. Other input devices (not shown)may include a microphone, joystick, game pad, satellite dish, scanner,or the like. These and other input devices are often connected to theprocessing unit 21 through a serial port interface 46 that is coupled tothe system bus, but may be connected by other interfaces, such as aparallel port, game port or a universal serial bus (USB). A monitor 47or other type of display device is also connected to the system bus 23via an interface, such as a video adapter 48. In addition to themonitor, personal computers typically include other peripheral outputdevices, not shown, such as speakers and printers.

[0032] The personal computer 20 may operate in a networked environmentusing logical connections to one or more remote computers, such as aremote computer 49. The remote computer 49 may be another personalcomputer, a server, a router, a network PC, a peer device or othercommon network node, and typically includes many or all of the elementsdescribed above relative to the personal computer 20, although only amemory storage device 50 has been illustrated in FIG. 1. The logicalconnections depicted in FIG. 1 include a local area network (LAN) 51 anda wide area network (WAN) 52. Such networking environments arecommonplace in offices, enterprise-wide computer networks, intranets andthe Internet.

[0033] When used in a LAN networking environment, the personal computer20 is connected to the local network 51 through a network interface oradapter 53. When used in a WAN networking environment, the personcomputer 20 typically includes a modem 54 or other means forestablishing communications over the WAN 52. The modem 54, which may beinternal or external, is connected to the system bus 23 via the serialport interface 46. In a networked environment, program modules depictedrelative to the personal computer 20, or portions thereof, may be storedin the remote memory storage device. It will be appreciated that thenetwork connections shown are exemplary and other means of establishinga communications link between the computers may be used.

[0034] In the description that follows, the invention will be describedwith reference to acts and symbolic representations of operations thatare performed by one or more computer, unless indicated otherwise. Assuch, it will be understood that such acts and operations, which are attimes referred to as being computer-executed, include the manipulationby the processing unit of the computer of electrical signalsrepresenting data in a structured form. This manipulation transforms thedata or maintains it at locations in the memory system of the computer,which reconfigures or otherwise alters the operation of the computer ina manner well understood by those skilled in the art. The datastructures where data is maintained are physical locations of the memorythat have particular properties defined by the format of the data.However, while the invention is being described in the foregoingcontext, it is not meant to be limiting as those of skill in the artwill appreciate that various of the acts and operation describedhereinafter may also be implemented in hardware.

[0035] In accordance with the invention, generalized network addresstranslation functionality that allows the development of the intelligenttransparent proxy is provided to the transparent proxy application 104by the architecture illustrated in FIG. 9. This functionality includeskernel-mode support for proxy-controlled network address translationthrough the generalized network address translator (gNAT) 106, anduser-mode implementation of these redirect application programminginterface (API) 108 routines. In this way, the system of the instantinvention allows a transparent proxy application 104 to request that anetwork gateway modify the source and/or destination address of a givennetwork session in a manner transparent to the original source hostand/or the replacement destination host. This ability made available bythe instant invention allows true intelligent proxy-controlled arbitraryredirection on network sessions. While the application process 104 isillustrated in the user-mode, it should be recognized by those skilledin the art that the invention is not so limited to only user-modeapplications. Indeed, a network application 104 using the services ofthe gNAT 106 may reside in kernel-mode. In such a situation, the API 108would also exist in the kernel-mode, and such a situation is within thescope of the instant invention. Further, it should be recognized thatthe proxy application and the gNAT gateway may be physically located ondifferent computers, and that such implementation is also within thescope of the instant invention.

[0036] By generalizing the operation of network address translation andputting that operation under proxy 104 control, the system of theinstant invention allows the proxy 104 to achieve a number of benefits.This functionality may be used to redirect sessions to support migrationof services for enhanced availability. This functionality is unique tothe system of the instant invention in that the application programminginterface 108 allows proxy applications 104 to gain explicit controlover the translation performed by the gNAT 106, unlike traditionaltransparent proxies which do not have any control over the NAT tocommand dynamic address redirection.

[0037] Further, since the traditional transparent proxy transfersinformation between separate network sessions, it typically suffersperformance degradation. As discussed, this is because the network datamust be received from the network for one of the proxy's sessions,delivered to the user-mode proxy by the kernel-mode network transport,read by the proxy, written to the proxy's other session, transferred tothe kernel-mode driver, and transmitted to the network for the proxy'sother session. Instead of taking the above steps to copy data from onenetwork session to another, the application programming interface 108allows such proxies 104 to instruct the network gateway or generalizedNAT (gNAT) 106 to translate one network session into another.

[0038] As may be seen from the architectural diagram of FIG. 9, thesystem of the instant invention comprises a kernel-mode translationmodule 106 that processes packets received from the network and modifiesthose packets in real-time in accordance with dynamic redirectinstructions from the transparent proxy 104. The system further includesa user-mode application programming module 108 that implements theinterface invoked by transparent proxy 104. As will become apparent fromthe following description, the application programming module 108consists of two API suites that together enable the development of theintelligent transparent proxy of the instant invention.

[0039] The first of the two API suites provides the dynamic redirect APIroutines. These routines allow an application process to redirect toitself all sessions for a certain TCP or UDP port number (e.g.,redirecting all HTTP sessions to a local socket). These API routinescause the requests from clients to be translated in such a way that theyare delivered by the network gateway to the application process, ratherthan being forwarded through the normal mechanism to the client'sintended server.

[0040] The second of the two API suites provides the port-reservationAPI routines. These routines allow an application process to reserve foritself blocks of TCP or UDP port numbers. In the process of acting as atransparent proxy, the proxy may find it necessary to intervene in theestablishment of additional network sessions between a client and aserver. In order to do so, the process of the instant invention may needto replace port numbers advertised by clients with port numbers valid onthe proxy process's host machine. To address this requirement, routinesare provided to allow the transparent proxy to reserve TCP and UDP portnumbers for its own use, with the assurance that the reserved numberswill not be allocated for use by any other applications.

[0041] The kernel-mode translation module 106 performs the functions ofa generalized network address translator (gNAT). This module 106 isimplemented in a preferred embodiment as a Windows 2000 driver thatregisters itself as a firewall driver with the Windows 2000 TCP/IPdriver 110. Of course, one skilled in the art will readily appreciatethat this module may also be adapted to operate in other operatingsystems without undue experimentation and without departing from thescope and spirit of the instant invention. Therefore, these alternateembodiments are hereby reserved. In its registration, the module 106supplies an entry-point that is called by the TCP/IP driver 110 uponreception of every incoming packet and before transmission of everyoutgoing packet. This ensures that all packets will be observed by thekernel-mode translation module 106 before being sent, received, orforwarded.

[0042] Each proxy-requested translation is recorded by the kernel-modetranslation module 106 as a redirect. Such a redirect consists of adescription of the session to be translated, along with a description ofthe translation to be performed. For example, the description of thetranslation may state that when a session is detected with sourceaddress S and destination address D, translate it so that the sourceaddress becomes S′ and the destination address becomes D′. When themodule 106 detects any new network session, it determines whether thereis a redirect that applies to the session. If the module 106 determinesthat there is a redirect for this session, the redirect is activated.The network session is automatically translated and a mapping is createdto ensure that the same translation is done for all packets in thesession. The normal processing is then continued on the session'stranslated packets, causing them to be delivered locally or forwardeddepending on the new source and destination.

[0043] The user-mode application programming module 108 is alsopreferably implemented as a Windows 2000 library that is loaded by thetransparent proxy application 104. As with the above, the invention isnot so limited to a particular operating system, but is applicable toany operating system which allows network communication. Therefore, theexemplary embodiments described herein are by way of illustration andnot by way of limitation. A proxy application 104 calls the library 108to initialize the kernel-mode translation module 106, and then createsone or more redirects for the network sessions to be translated. Toallow the proxy 104 to add value and observe the requested sessions, theinitial redirects commanded by the proxy 104 provide redirection of allmessage packets up to the proxy 104.

[0044] Using the API routines provided by the NAT API 108, a processmight act as a transparent proxy for HTTP sessions, for example, bystarting up, binding to a local socket, and initializing the transparentproxy API library on the network gateway machine. The transparent proxy104 then retrieves the address of its local socket and invokes thetransparent proxy API 108 to create a ‘dynamic port-redirect’ for TCPport number 80 (which is the HTTP port) using its local socket'saddress. While this exemplary operation is described for an HTTP port,one skilled in the art will recognize that the dynamic port-redirect maybe accomplished for any port number.

[0045] The port-redirect command tells the API library 108 to instructthe network gateway that all sessions destined for TCP port number 80must be directed instead to the transparent proxy's socket. As a clientstarts an Internet browser, it sends a connection-request to TCP portnumber 80 of a server on the Internet through the network gateway. Thenetwork gateway determines that the client's connection-request matchesthe transparent proxy's commanded redirect, and it triggers thekernel-mode network address translation module 106.

[0046] The kernel-mode translation module 106 changes the destinationaddress of the client's connection-request to be the local address ofthe transparent proxy's socket, records the change made in a translationmapping, and returns the connection request to the network gateway. Thenetwork gateway forwards the client's connection-request, which is nowdestined for the transparent proxy instead of the Internet server towhich the request was originally sent. The transparent proxy 104receives the client's connection-request and invokes the transparentproxy API 108 to determine the address of the Internet server to whichthe request was originally sent. The transparent proxy 104 performsprocessing on the client's request, including optionally initiating asecondary connection on the client's behalf to the original targetInternet server or to another server or servers. The transparent proxy104 then sends responses to the client, which pass through the networkgateway and are translated by the kernel-mode translation module 106 sothat the client continues to believe that it is communicating with itsoriginal target Internet server.

[0047] In a preferred embodiment, the library 108 provides routines toperform at least the initializing and shutting down of the library. Theinitialization ensures that the kernel-mode translation module 106 isloaded and registered in preparation for translating network sessions.The shutting down of the library concludes the proxy's use of thekernel-mode translation module, which may be unloaded if it has no otherclients. Further, the library 108 also includes routines for creating aredirect for a network service. This operation supplies informationidentifying a network service, along with information describing thetranslation to be done for all clients of the network service. Itsprotocol, its destination port, its replacement destination IP address,and its replacement destination port identify a network service. Theprotocol indicates the transport-layer protocol of the network session,which may be either TCP or UDP. The destination port indicates the portnumber of the network service, e.g. port 80 for the HTTP service. Anyclient attempting to connect to this port on any Internet server is thenredirected to the host given as part of this dynamic redirect.

[0048] The replacement destination IP address indicates the IP addressof the host to which any matching session should be redirected. Thereplacement destination port indicates the port number to which anymatching session should be redirected on the given host. By replacingthe port number rather than retaining the service's original portnumber, a transparent proxy can be more flexible about which port numbercan be used for the socket on which it accepts clients' requests. Thelibrary also provides retrieving of the original destination for aredirected network session. This operation supplies the original sourceand destination for a network session which has been redirected by thenetwork gateway, given the post-redirection source and destination forthe session. This information is retrieved by the network gateway fromthe translation mapping maintained by the kernel-mode translation module106 for each translated session. Finally, the library provides routinesto cancel a redirect for a network session. This operation revokes aprevious translation-request issued by the proxy 104.

[0049] The port-reservation API is implemented as part of the Windows2000 library 108 that contains the dynamic redirect API routines. Thetransparent proxy 104 calls the library upon initialization, and thencreates one or more port pools that contain port numbers reserved fromthe network gateway's range of TCP and UDP port numbers. The proxy canthen reserve and release port numbers from the created pools. Theroutines provided by the library include creating and destroying a portreservation, and acquiring and releasing a port number. The creation ofa port reservation prepares the network gateway to receive requests forport numbers from the library, and returns a handle to the networkapplication that can be used for requesting port numbers. The destroyingof a port reservation destroys a handle supplied by the previousoperation, returning all outstanding port numbers to the networkgateway. The acquiring of a port number from a reservation requests oneor more contiguous port numbers from the network gateway. Finally, thereleasing of a port number to a reservation returns one or morepreviously acquired contiguous port numbers to the network gateway.

[0050] The operation of translating network sessions at thetransport-layer is illustrated in FIG. 10 to which specific reference isnow made. Upon establishment of a network session by the receipt ofnetwork data on session line 112, the data is communicated to the proxy104. Upon processing by the proxy 104, this initial data is copied to asecond session 114, and transmitted to the network by the driver 110.This initial operation is much like a traditional proxy, except that thegNAT 106 may transparently redirect the data to the proxy 104 even ifthe client process is not aware of the network application, much like atraditional transparent proxy. Unlike a traditional or transparentproxy, the transparent proxy 104 of the instant invention is now able toutilize the API 108 to command (illustrated by line 116) a dynamicredirect so that further data transitions from kernel-mode to user-modeare no longer required. This establishes a fast-path for proxy-likeapplications in which datagrams must be copied from one session toanother. This fast-path transfer is ideal for data streamingapplications, on-line gaming, multi-party conferencing, etc.

[0051] Once the proxy 104 has determined that a dynamic redirect isappropriate and such has been commanded of the gNAT 106, it establishesa dynamic redirect mapping 118. All network data that is received fromthe network for the proper proxy's session (as determined by the gNAT106 in accordance with its commanded dynamic redirect 118) isautomatically translated by the gNAT 106 so that its transport-layeraddress matches the proxy's other session. This data is then transmittedto the network for the proxy's other session. Graphically, this dynamicredirection at the transport layer is illustrated by line 120. As may beseen from line 120, the communication of the data to the network serverno longer requires that the data go through two kernel-user modetranslations, i.e. the trip to the proxy 104 is short circuited.Likewise, return data on line 122 may also be dynamically redirected tothe client if so commanded by the proxy 104. The approach allows suchapplications to achieve a considerable improvement in their performance.

[0052] This performance improvement becomes vividly apparent if theinitial communication on line 112 opens an ftp control session carryingan ftp get file request. Under a traditional transparent proxy scenario,the ftp data channel created to receive the file requested would firstbe passed from the kernel-mode to the user-mode to the proxy, and thenwould be passed back down to the kernel-mode to be forwarded to theclient. As may well be imagined, this process incurs significantperformance degradation, especially if the file is quite large. Underthe system of the instant invention, however, the network application104 may open a data session that does not require any transitions to theuser-mode by commanding a dynamic redirection at the transport-layer.Now, as the data is received from the ftp server, the gNAT 106 performsthe dynamic redirection in accordance with the intelligent transparentproxy's command. The destination address of the data is simplytranslated and passed to the client as indicated by line 122.Significant performance improvement is achieved in this way.

[0053] The system of the instant invention also allows session payloadediting. Certain applications include addressing information within thedata streams of their sessions. For instance, many streamingapplications use a control session to establish a secondary data sessionsimilar to that described above. This poses a problem for a traditionalNAT in its primary application, i.e. transparent sharing of a singleInternet connection among multiple machines. When running on clientsthat are sharing a connection, such applications would send private,unreachable addressing information to remote peers, and the latter wouldbe unable to respond to the clients' requests. To solve this problem,the system of the instant invention supports an extensible means ofmodifying a session's application-layer data in flight, beyond themodifications made to the session's network-layer and transport-layeraddressing information. Extensibility is achieved by allowingthird-party drivers to inspect the application-layer data in each packetreceived for a session, and to edit the application data in each packet.These editors register themselves with the gNAT of the instant inventionas handlers for a specific TCP/UDP port number, and are henceforthinvoked for each message translated in matching sessions.

[0054] In operational terms, the dynamic redirection made available bythe system of the instant invention is illustrated in FIG. 11. Asillustrated therein, a client process C₁ on a private network 123 sendsa message packet destined to server S₁ on a public network 125. Theapparent path of the message packet is as illustrated by dashed line127. However, when the message packet hits the dynamic redirect 129 ofthe gateway machine 131 running the intelligent transparent proxyapplication, the message packet is redirected to a proxy session 133.The intelligent transparent proxy of the instant invention then servicesthis message packet by, in this case, forwarding it to a second session135 for transport to the server S₁. The proxy could have denied themessage packet, forwarded it to a local server (not shown) forservicing, serviced the message itself, etc.

[0055] Typical transparent proxies also service the responsivecommunication from the server S₁ as a matter of course. While this isalso possible with the intelligent transparent proxy of the instantinvention, it may decide to open a fast-path data transfer session andforego transitions to and from the user-mode in the gateway machine. Theproxy accomplishes this by commanding a dynamic redirect to be mapped inthe gNAT. When the server S₁ responds (illustrated by line 137), themessage packet is seen by the gNAT, which verifies that it has a proxycommanded redirect for that message, and is redirected at thetransport-layer to the client C₁ as indicated by line 139. Thistransmit-proxy, receive-NAT functional operation significantly improvesthe performance of the system, especially in situations of datastreaming, multi-party conferencing, multi-party gaming, etc.

[0056] A further dynamic redirection that may be commanded by theintelligent transparent proxy of the instant invention is illustrated inFIG. 12. A client C₁ may wish to establish a session with server S₁ byaddressing messages thereto. This is the apparent session from theclient C₁'s point of view, as illustrated by the dashed line 124.However, when the gNAT machine 126 detects the message from C1 addressedto S1, it checks to determine if a dynamic redirect exists for such asession as discussed above. As illustrated in FIG. 12, a dynamicredirect 128 does exist to forward the message to the proxy session 141.The proxy may include a translation of both the source and destinationaddresses such that the messages are actually forwarded by the proxy toserver S₂ with an indication that the source was C₂. From the serverS₂'s point of view, an apparent session 130 has been established betweenS₂ and C₂. The actual session 132 that has been established is betweenC₁ and S₂, although neither C₁ nor S₂ knows that this is the case. Eachof the required translations is accomplished transparently.

[0057] As described above, the intelligent transparent proxy may use theNAT API 108 (see FIG. 9) to command a dynamic redirect in the gNAT 106so that when messages are received from server S₂ they may be properlyrouted to the correct client (C₁). This dynamic redirection may becommanded to take place at the transport-layer (kernel-mode) to speedperformance, or may require that the messages be forwarded up to theproxy for processing prior to being delivered to the client. Indeed, theproxy may decide not to forward the message at all (e.g. based on siteblocking or parental control programming within the proxy). Since thegNAT allows dynamic address translation of both source and destinationIP addresses, the proxy can command various translations that may bemade at the transport-layer, establishing any number of apparentsessions as desired. Placing this dynamic redirection ability under theexplicit control of the proxy provides significant advantages, not theleast of which is performance improvement. Indeed, this system allowsthe benefits of both proxies and NATs to be achieved at each datasession. Further, these advantages may be maximized under proxy controlfor each session, i.e. for the transmission, reception, and redirectionof message flow as well as for control versus data sessions.

[0058] All of the references cited herein, including patents, patentapplications, and publications, are hereby incorporated in theirentireties by reference.

[0059] In view of the many possible embodiments to which the principlesof this invention may be applied, it should be recognized that theembodiment described herein with respect to the drawing figures is meantto be illustrative only and should not be taken as limiting the scope ofinvention. For example, those of skill in the art will recognize thatthe elements of the illustrated embodiment shown in software may beimplemented in hardware and vice versa or that the illustratedembodiment can be modified in arrangement and detail without departingfrom the spirit of the invention. Therefore, the invention as describedherein contemplates all such embodiments as may come within the scope ofthe following claims and equivalents thereof.

I claim:
 1. A method of communicating between a user-mode proxyapplication program and a kernel-mode translation module to dynamicallyredirect network sessions, comprising the steps of: receiving from theuser-mode proxy application program a create a dynamic redirect callhaving a plurality of call parameters comprising a transport-layerprotocol of the network session, a destination IP address of the networksession to be redirected, a destination port number of the networksession, a replacement destination IP address of a host to which amatching session should be directed, and a replacement destination portnumber to which any matching session should be redirected; parsing thecreate a dynamic redirect call to retrieve the parameters; andcommanding the kernel-mode translation module to create the dynamicredirect based on the parameters.
 2. The method of claim 1, wherein thestep of receiving comprises the step of receiving from the user-modeproxy application program the create a dynamic redirect call having aplurality of call parameters comprising a transport-layer protocol ofthe network session set to TCP.
 3. The method of claim 1, wherein thestep of receiving comprises the step of receiving from the user-modeproxy application program the create a dynamic redirect call having aplurality of call parameters comprising a transport-layer protocol ofthe network session set to UDP.
 4. The method of claim 1, wherein thestep of receiving comprises the step of receiving from the user-modeproxy application program the create a dynamic redirect call having aplurality of call parameters comprising a destination port number set to80 for a HTTP service.
 5. The method of claim 1, wherein the step ofreceiving comprises the step of receiving from the user-mode proxyapplication program the create a dynamic redirect call having aplurality of call parameters comprising a replacement destination portthat is different than the destination port number.
 6. The method ofclaim 1, wherein the step of commanding the kernel-mode translationmodule to create the dynamic redirect based on the parameters comprisesthe step of commanding the kernel-mode translation module to create thedynamic redirect within the kernel-mode, without a translation to theuser-mode, based on the parameters.
 7. A method of communicating betweena user-mode proxy application program and a kernel-mode translationmodule to dynamically redirect network sessions, comprising the stepsof: receiving from the user-mode proxy application program a retrieve anoriginal destination call having a plurality of call parameterscomprising a post-redirection source and destination for the session;parsing the create a dynamic redirect call to retrieve the parameters;and requesting the kernel-mode translation module to retrieve theoriginal destination for the session from a translation mapping based onthe parameters.
 8. The method of claim 7, further comprising the step ofreturning to the user-mode proxy application the original destinationfor the session.
 9. A method of communicating between a user-mode proxyapplication program and a kernel-mode translation module to dynamicallyredirect network sessions, comprising the steps of: receiving from theuser-mode proxy application program a create a dynamic redirect callhaving a replacement destination IP address of a host to which thenetwork sessions should be directed call parameter; parsing the create adynamic redirect call to retrieve the parameter; and commanding thekernel-mode translation module to create the dynamic redirect based onthe parameter.
 10. The method of claim 9, wherein the step of commandingthe kernel-mode translation module to create the dynamic redirect basedon the parameter comprises the step of commanding the kernel-modetranslation module to create the dynamic redirect within thekernel-mode, without a translation to the user-mode, based on theparameter.
 11. A method of communicating between a user-mode proxyapplication program and a kernel-mode translation module to dynamicallyredirect network sessions, comprising the steps of: receiving from theuser-mode proxy application program a create a dynamic redirect callhaving a replacement destination port number to which the networksessions should be redirected call parameter; parsing the create adynamic redirect call to retrieve the parameter; and commanding thekernel-mode translation module to create the dynamic redirect based onthe parameter.
 12. The method of claim 11, wherein the step ofcommanding the kernel-mode translation module to create the dynamicredirect based on the parameter comprises the step of commanding thekernel-mode translation module to create the dynamic redirect within thekernel-mode, without a translation to the user-mode, based on theparameter.
 13. A method of communicating between a user-mode proxyapplication program and a kernel-mode translation module to dynamicallyredirect network sessions, comprising the steps of: receiving from theuser-mode proxy application program a create a dynamic redirect callhaving a plurality of call parameters comprising a transport-layerprotocol of the network session, a destination IP address of the networksession, and a replacement destination IP address of a host to which amatching session should be directed; parsing the create a dynamicredirect call to retrieve the parameters; and commanding the kernel-modetranslation module to create the dynamic redirect based on theparameters.
 14. The method of claim 13, wherein the step of commandingthe kernel-mode translation module to create the dynamic redirect basedon the parameters comprises the step of commanding the kernel-modetranslation module to create the dynamic redirect within thekernel-mode, without a translation to the user-mode, based on theparameters.
 15. A method of communicating between a user-mode proxyapplication program and a kernel-mode translation module to dynamicallyredirect network sessions, comprising the steps of: receiving from theuser-mode proxy application program a create a dynamic redirect callhaving a plurality of call parameters comprising a transport-layerprotocol of the network session, a destination port number of thenetwork session, a destination IP address of the network session, asource port number, a source IP address, a replacement source IPaddress, a replacement port number, a replacement destination IP addressof a host to which a matching session should be directed, and areplacement destination port number to which any matching session shouldbe redirected; parsing the create a dynamic redirect call to retrievethe parameters; and commanding the kernel-mode translation module tocreate the dynamic redirect based on the parameters.
 16. The method ofclaim 15, wherein the step of commanding the kernel-mode translationmodule to create the dynamic redirect based on the parameters comprisesthe step of commanding the kernel-mode translation module to create thedynamic redirect within the kernel-mode, without a translation to theuser-mode, based on the parameters.